Size Report

Startup median (7 runs, lower is better):

Top changed chunks:

Review: recover Android snapshots from degraded helper output

Verdict: not merge-ready as-is — your own PR description says as much. Two things to address before it lands.

1. The classifier doesn't cover the actual #850 repro (blocking)

classifyAndroidHelperContentRecovery only triggers a fallback in two cases:

• empty-helper-output: summary.nodeCount === 0 || metadata.nodeCount === 0 || metadata.rootPresent === false
• system-window-only: summary.windowRootCount > 0 && summary.applicationWindowRootCount === 0

The reported Fabric/newArch case is neither. Per your own live note the helper returned "status-bar nodes plus an Expo/Compose 'Tools' overlay, with backend=android-helper and no fallback" — i.e. an application window is present (or the content carries no window-type wrappers at all). Trace it:

• nodeCount > 0 and rootPresent === true → branch (a) skipped
• applicationWindowRootCount > 0 or windowRootCount === 0 (when content has no window-type attrs — exactly the shape of your own androidFabricAppXml() fixture) → branch (b) skipped
• → returns undefined → no fallback

So the classifier handles "no app window" but not "app window present but content-poor", which is the bug. The new test keeps helper output when application and system windows are both present actually encodes this gap as intended behavior, and the other new tests only exercise the empty / system-only paths — so the suite goes green while #850 is still broken.

What's missing is a content-quality signal, e.g.:

• app window present but interactive/text node count below a threshold, and/or
• the foreground app package (you already plumb appBundleId through in fix: clean up Android snapshot helper sessions #862) not represented among meaningful nodes.

2. Heavy overlap with #862 (blocking on ordering)

Both PRs rewrite the same region of captureAndroidUiHierarchyWithHelper in snapshot.ts. #862 renames getAndroidSnapshotHelperDeviceKey → getAndroidSnapshotHelperSessionDeviceKey, converts captureAndroidUiHierarchyFromHelper to a params object, and adds a finally that stops command-scoped sessions. This PR inserts content recovery into the same function and calls stopAndroidSnapshotHelperSession / resetAndroidSnapshotHelperRuntime in a new recovery path. They will conflict.

Suggested order: land #862 first, rebase this on top, and let recoverAndroidHelperContentUnavailable rely on #862's finally for session teardown rather than stopping again (idempotent, so not a correctness bug — just redundant work).

Recommend converting to draft until the classifier covers the content-poor app-window case; otherwise this merges a passing test suite that doesn't fix the linked issue.

_{🤖 Automated review via Claude Code}

Addressed the review blockers:\n\n- Stacked #861 on #862 by retargeting the base to fix/android-snapshot-helper-lifecycle; the recovery path now relies on #862's command-scoped session cleanup and only resets the helper runtime before stock UIAutomator fallback.\n- Broadened the classifier beyond empty/system-only output. It now treats content-poor foreground-app helper captures as degraded using bounded app-content quality counts, with appBundleId threaded from the Android interactor.\n- Added production-route coverage in snapshotAndroid for the content-poor foreground-app case, plus a healthy app+system window case that stays on the helper path.\n\nValidation after the rebase: pnpm check:quick, pnpm build, and pnpm exec vitest run src/platforms/android/__tests__/snapshot.test.ts pass. pnpm check:unit still has three unrelated Android fill timeout failures in src/platforms/android/__tests__/index.test.ts.

Latest review found a blocker: src/platforms/android/ui-hierarchy.ts now only treats a covering sibling as real if the covering node itself has label/id/hittable state. That fixes the transparent Expo container case, but a common unlabeled full-screen RN/modal/navigation container with visible child actions could stop covering lower drawing-order siblings and re-expose hidden background controls. The regression test was weakened by adding content-desc="Foreground surface", so it no longer protects the unlabeled-container case. Please restore coverage for an unlabeled covering container with visible children, adjust pruning so transparent helper containers are ignored without re-exposing background controls, and update the e2e evidence before moving this out of draft.